The Domain Name System (“DNS”) associates various sorts of information with so-called “domain names” and provides for a user friendly addressing process for the Internet by translating human-readable computer hostnames into the IP addresses. This process is known as “name resolution” and may be handled in various ways, but the most common method is for name translations to occur through the DNS system (hereinafter “Internet DNS” or simply “DNS”). For example, the numerical address 66.230.200.100 is provided to Internet users' machines when the human readable address www.wikipedia.org is typed into an Internet browser addressing bar. The translation of a domain name or other human readable text into IP addresses provides the addressing scheme that networking equipment needs to deliver webpages to PCs around the world, and to provide other information such as addresses for mail exchange servers and other services available over the Internet. In providing a worldwide keyword-based addressing scheme (i.e. essentially a redirection service), DNS is a critical component for the functioning of today's Internet. The Internet is the medium through which most information is exchanged across the world.
While other computer programs exist that process name resolution requests from computer to computer, as of the filing of this application the most prevalent method for name resolution is dictated by the DNS process as invented by Paul Mockapetris in 1983 and governed by RFC (“Request for Comment”) 1034 and 1035 as adopted by the Internet Engineering Task Force (IETF) in 1986. RFCs 1034 and 1035 made obsolete the prior RFCs 882, 883, 973 as adopted circa 1983-84. DNS is one of the original Internet standards, although new applications and extensions to DNS are continually being evaluated by IETF and the Internet community at large. The RFCs 1034 and 1035 specification is hereby incorporated by reference.
While the total scope and operation of DNS is not necessary for a complete understanding of the herein described invention, a few concepts are described below to facilitate in the description of the invention's preferred embodiments.
Name resolution in its simplest form is achieved by an ASCII text conversion table stored on each computer, traditionally know as a “HOSTS” file. At a local network level, a lookup table is maintained to list different machines that are added to the network and assigned numbers associated with each machine name through a program such as Windows DHCP program. The lookup table on a local network is updated only once for each new machine that is added (e.g. a new PC, a router, a printer, etc.) and is usually administered by a local DNS type program, such as the Microsoft Windows based program “WINS” (Windows Internet Name Service). Since HOST files are updated manually, and since even an automatically updated conversion file saved on a local machine would become impossibly large to accommodate all of the domain names used on the Internet, DNS changes this to delegate the lookup or resolution process across a distributed plane of name servers.
When an entity registers a human readable domain name (currently, letters and numbers and a few special symbols, but this is being expanded) with one of the dozens of ICANN authorized registrars (e.g. www.register.com), the registering entity specifies two DNS servers associated with a selected domain name, a primary and a backup DNS server. These servers are the authoritative sources for DNS information regarding the selected domain name and machines connected to a network on the domain. When a user of the Internet attempts contact a system in the network domain of the registered domain name, the machine utilized by the user will check progressively from its own DNS server's lookup table, to other machines connected thereto, to Internet core servers, and finally to the authoritative servers themselves to translate the spelled name into an IP address. This occurs through the action of a program in the DNS system called a “recursor” that sends and responds to addressing queries from other DNS servers in an iterative process. Currently, a popular UNIX based DNS resolution program that includes a recursor is BIND (“Berkeley Internet Name Domain”). Responses from these recursor programs usually are either error messages or a “pointer” to which the recursor program might send additional queries to find the host machine. Upon receiving a request, a DNS server contacted by a recursor program of another DNS server can respond in four ways:                1. It can answer the request with an IP address because it already knows the IP address for the domain.        2. It can contact another name server and try to find the IP address for the name requested. It may have to do this multiple times.        3. It can say, “I don't know the IP address for the domain you requested, but here's the IP address for a name server that knows more than I do.”        4. It can return an error message because the requested domain name is invalid or does not exist.This process is iteratively continued until a name is resolved and the host computer is contacted.        
Once the resolution process is complete, in theory, various DNS server machines, and other intermediate name resolution machines, will propagate the human readable name's IP address association to their tables so that name resolution is facilitated across the Internet. Further, local DNS tables are configured to retain information (referred to as “caching”) so that addresses used most often by its domain users are quickly accessible to facilitate the rapid functioning of DNS.
Very often, an ISP like “yahoo” or “Earthlink” will administer domain names and their associated webpages and resources for an entity. But, quite often, organizations will maintain their own domain name and resources. For example, “HowStuffWorks” a well known information Internet site maintains their own machines dedicated to their website, including administering their own DNS server. As published on their website, they have a primary server and a secondary, as such:
AUTH-NS1.HOWSTUFFWORKS.COM 209.116.69.78
AUTH-NS2.HOWSTUFFWORKS.COM 209.116.69.79
Their primary DNS is auth-ns 1.howstuffworks.com and any changes they make to this site is automatically propagated to the listed secondary site, which is maintained not by them, but by their ISP.
HOWSTUFFWORKS uses the name server software BIND for their domain and they have a zone file (similar to the functioning of a HOST file, but formatted for DNS on their host DNS server having the following form:
@NSauth-ns1.howstuffworks.com.@NSauth-ns2.howstuffworks.com.@MX 10mailmailA209.170.137.42vip1A216.183.103.150wwwCNAMEvip1
This is a typical zone file and has the following meaning. The first two lines point to the primary and secondary name servers. The next line is called the “MX record” which indicates the e-mail SMTP server. The next line indicates the machine that handles a request to mail.howstuffworks.com. The next line indicates to the IP address that will handle a request to oak.howstuffworks.com. The next line points to the IP address that will handle a request to howstuffworks.com (no host name). This last line is also know as the “A NAME” record which lists the primary computer IP address.
As seen in the information in the zone file, several physical computer machines at separate IP addresses make up the computer server infrastructure for the website www.howstuffworks.com.
One will also note that a “CNAME” record appears in the above zone file on the last line. CNAME is short for “canonical name,” which is usually referred to as a CNAME record. A CNAME record in a DNS database, like the zone file above, is a record that indicates the true, or “canonical,” host name of a computer with which its aliases are associated.
CNAME records can be used when a computer or service needs to be renamed to temporarily allow access through both the old and new name, or to point a sub-domain to another domain, or to have a sub-domain point to a computer outside of the host domain. In the above zone file example, the CNAME record redirects all world web entries http://www.howstuffworks.com to the vip1 server IP address listed under the A Name record. CNAMES are often used to redirect address bar mistakes entered into Internet browser software fields. For example, many HOST record files redirect incorrect entries like http://wwww.domainname.com and http://ww.domainname.com to http://www.domainname.com, which is helpful for instances when an Internet user do not enter the correct number of “w”s in the browser address bar of their Internet browser program like Internet Explorer. The complete usage and acceptable forms of CNAMEs may be found in RFC 1034.
However, while usage of CNAMES provides a flexible means for redirecting access to websites, domains, sub-domains, resource records, etc., the common method for altering the zone file or equivalent DNS record file is manual editing of the file. While some useful interfaces are available to make the process simpler, the action is consistent—alteration of the text in a text file.
However, when a website becomes inoperative because the server machines that hold the DNS record file no longer function, such as when a natural disaster damages computer equipment or denies power, cuts communication paths, or causes the loss of other critical computer support infrastructure, a lack of a DNS server response causes an error in the DNS system for that system. Alternatively, if a known IP address is retained from prior DNS resolution activities, but the computer server providing the resource record is not functioning, an error will be generated. Hence, without manual alteration of a DNS record file held by an alternative host computer, which will cause a delay in propagation of the revised DNS record of up to several days, a website made inoperative by a natural disaster would be inaccessible for several days or months, with restoration only occurring if the organization had the foresight to retain a backup of all prior information and has personal ready to quickly edit the appropriate DNS records to provide new IP addresses for the content. If the authoritative host machine was made by a natural disaster inoperative, which would not be uncommon for self-administered sites, the disruption could last for some time, and certainly a website held on a web server maintained by the entity would be inoperative during and just after the disaster event.
Text messaging communications have been available in one form or another since the early 1990s. Generally, text messaging consists of the transference of a limited string of ASCII characters, typically between 64 and 256 characters, between one electronic device and another. However, after the promotion and competition of various standards since 1995, text messaging via SMS (Short Messaging Service) has become the ubiquitous conduit for mobile devices, such as cellular phones, to communicate text messages. While at one time, SMS communications was relegated to communications between mobile devices on the same network, such as for example the T-Mobile™ network, various protocol agreements have been implemented so that any phone (or cellular voice or cellular data mobile device) may send an SMS message to any another, and from any computer to a mobile device, irrespective of the mobile carrier network upon which the device operates. An example of one system that allows for the protocol compatibility between various carriers may be found in U.S. Pat. Publication No. US 2003/0109271 submitted by John E. Lewis of Cingular Wireless, Atlanta, Ga. This Lewis publication is hereby incorporated by reference into this application in its entirety.
According to CTIA (Consumer Telecommunications Industry Association; aka “The Wireless Association”), as of June 2010, there were over 282 Million wireless subscribers in the U.S., with an estimated 1.81 Trillion text messages being sent annually among them. Hence, SMS communications have emerged as a primary communications tool among the U.S. populace and the integration of an emergency alert system into the cell phone SMS infrastructure would facilitate the propagation of emergency alert messages.
Therefore, in response to a quick and simple “deflection” (e.g. re-routing or redirecting) of inquires to a website on the Internet, most likely upon the occurrence of a natural disaster or the immanent occurrence of a natural disaster, the dissemination of emergency alert messages through the SMS cellular phone infrastructure would increase the likelihood that the U.S. populace would rapidly and efficiently receive such alerts.